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Abstract-  Procedures  are  proposed  to  assist  the  Navy  Management  Systems 
Support  Office  in  performing  software  maintenance.  Hardware  and  software 
maintenance  are  contrasted.  The  key  difference  between  the  two  —  the  ease 
with  which  software  can  be  changed  —  leads  to  the  need  for  managing 
software  change.  Standardi zati on  of  software  maintenance  is  proposed  as  the 
method  for  managing  software  change.  A  model  of  software  maintenance  is 
advanced  as  the  foundation  for  standardizing  software  maintenance. 

I.  INTRODUCTION 

Software  maintenance  is  a  major  activity  at  the  Navy  Management  Systems 
Support  Office  (NAVMASSO).  This  report  is  provided  to  assist  NAVMASSQ  in 
its  maintenance  operations.  The  report  describes  procedures  for 
standardizing  maintenance.  The  report  makes  the  argument  that  a  major 
attack  on  the  maintenance  problem  can  be  made  through  standardization. 
Although  the  examples  are  oriented  to  local  area  network  software  and  batch 
files,  whereas  NAVMASSO  uses  COBOL,  the  procedures  are  general  and  can  be 
applied  in  any  software  development  and  maintenance  environment. 

NAVMASSO  is  one  of  the  few  organizations  to  recognize  the  importance  of 
software  maintenance.  Most  organi zati ons  emphasize  development  with  the 
need  for  maintenance  being  an  afterthought.  NAVMASSO 's  concern  for 
maintenance  is  exemplified  by  its  document  'NAVMASSO  Data  Processing 
Standard  No.  22. A:  Program  Specification  and  Maintenance  Procedures 
Standard  * ,  26  August  19S5.  The  purpose  of  this  standard  'is  to  describe  the 
program  design  in  enough  detail  to  permit  coding  by  the  programmer  and  to 
provide  the  maintenance  programmer  personnel  with  the  information  necessary 
to  effectively  maintain  the  system. *  Included  in  the  standard  is  the 
objective  of  incorporating  program  maintenance  procedures  into  the  program 
specification.  This  approach  integrates  maintenance  with  development,  thus 
forcing  consideration  of  maintenance  early  in  the  life  cycle.  Equally 
important  is  the  section  on  'Flexibility'  which  describes  the  capability 
for  adapting  the  program  to  changing  environments.  Providing  the  capability 
to  adapt  to  changing  environments  is  the  essence  of  the  software 
maintenance  problem  and  is  the  issue  which  motivated  this  research  reports 
we  view  software  maintenance  as  a  process  of  change  management.  It  is 
important  to  note  that  it  is  not  only  the  software  that  changes;  the 
documentation  changes  also.  This  important  aspect  of  maintenance  is 
recognized  in  NAVMASSQ 's  document  'NAVMASSO  Data  Processing  Standard  No. 
21. Bs  System  Documentation  Development  and  Control  Procedures',  19  June 
1985  in  which  document  changes/revisions  procedures  are  described. 

As  an  introduction  to  the  subject  of  software  maintenance,  we  provide 
some  definitions  followed  by  an  explanation  of  the  importance  of  the 
subject. 
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A.  Definitions 

Software  Maintenance:  Modification  of  a  software  product  after 

delivery  to  correct  faults,  to  improve 
performance  or  other  attributes,  or  to 
adapt  the  product  to  a  changed 
environment  E1D. 

This  definition  is  the  conventional  one  and  is  useful  if  our  interest  in 
modification  to  software  is  limited  to  changes  that  are  made  after  the 
software  is  delivered.  However,  it  is  a  fact  that  changes  are  not  confined 
to  the  post-delivery  phase;  they  are  made  during  all  life  cycle  phases.  In 
some  cases,  changes  are  made  in  significant  numbers  prior  to  delivery. 

Maintainability:  The  ease  with  which  a  software  can  be  maintained 

Ell. 

Change  Management:  The  process  of  making  changes  to  software 

and  controlling  their  effects  during  the 
entire  life  of  the  software. 

This  definition  recognizes  the  fact  that  modifications  to  software  must 
be  managed  effectively  during  the  entire  life  of  the  software.  It  is  the 
definition  used  here. 

B.  Cost  of  Maintenance 

According  to  various  sources,  software  maintenance  accounts  for  a 
significant  amount  of  the  total  time  and  cost  of  running  a  data  processing 
organization.  For  example,  one  study  reports  the  following:  about  half  of 
applications  staff  time  spent  on  maintenance,  over  40  percent  of  the  effort 
in  supporting  an  operational  application  system  spent  on  user  enhancements 
and  extensions,  and  about  half  a  man-year  of  effort  allocated  annually  to 
maintain  the  average  system  E23.  In  another  report  the  same  authors  list 
the  factors  which  cause  the  significant  maintenance  effort:  system  age, 
system  size,  relative  amount  of  routine  debugging,  and  the  relative 
development  experience  of  the  maintainers  E3D.  System  age  drives  the  other 
factors:  with  increased  system  age,  system  size  increases,  leading  to 
greater  effort  allocated  to  routine  debugging,  and  with  increased  system 
age,  the  relative  development  experience  of  the  maintainers  declines  due  to 
organizational  turnover  and  change.  All  of  these  factors  tend  to  increase 
the  time  and  cost  of  performing  maintenance.  Thus  maintenance  is  an  area 
that  deserves  a  lot  of  attention.  Improvements  in  maintenance  practices 
should  result  in  reduced  costs  and  increased  effectiveness  of  performing 
maintenance. 
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However  there  is  a  limit  to  reducing  cost  and  increasing  effectiveness 
through  improved  practices,  because  the  maintainability  of  the  software  has 
largely  been  determined  by  the  developer  before  it  ever  reaches  the 
maintainer.  The  maintainer  can  only  influence  quality  during  the 
maintenance  phase  of  the  software  life  cycle.  The  quality  of  the  software 
as  designed  is  determined,  in  part,  by  whether  the  software  development 
methodology  assists  the  developer  in  producing  maintainable  software. 
Consequently,  maintenance  practices,  which  maintainers  control,  and 
development  methodology,  which  developers  control,  are  candidates  for 
standardi z  at i on . 

C.  Limits  of  Approach 

The  objective  of  standardization  is  to  improve  the  maintainability  of 
both  existing  and  future  software.  Contrari wise,  there  are  certain  aspects 
of  the  'maintenance  problem'  that  the  above  approach  does  not  address. 
These  are  the  following:  1)  Much  of  the  software  that  is  maintained  was 
developed  without  benefit  of  any  methodology;  consequently,  methodology  is 
not  an  issue  in  these  cases;  2)  Methodology  is  only  an  issue  for  future 
software;  thus  improvements  in  maintenance  practices  are  only  applicable  to 
existing  software;  3)  An  important  determinant  of  the  maintainability  of 
software  is  the  knowledge  and  skill  of  the  developer  and  maintainer;  4) 
There  are  other  aspects  of  a  development  methodology,  such  as 
expressiveness,  that  are  important  when  evaluating  it  for  use  in  addition 
to  its  usefulness  as  an  aid  for  producing  maintainable  software.  These 
aspects  art  beyond  the  scope  of  the  paper  as  are  the  areas  of  software 
engineering  environments  and  tools,  which  can  contribute  significantly  to 
the  quality  of  both  development  and  maintenance. 

The  paper  consists  of  the  following  sections: 
o  Purposes 

o  Objectives  of  Maintenance 
o  Metrics  for  Maintenance 
o  Model  of  Maintenance 

o  Standardization  of  Change  Documentation 
o  Software  Communication  Mechanisms  and  Maintenance 
o  Standardization  through  Examination  of  Development  Methodologies 
o  Example 
o  Further  Research 
o  Summary 
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II.  PURPOSES 

The  purposes  of  the  paper  are  the  -following:  1)  Provide  a  brie-f 
introduction  to  software  maintenance  by  describing  its  objectives, 
processes  and  tasks,  contrasting  it  with  hardware  maintenance  for  the 
benefit  of  readers  who  may  be  more  familiar  with  hardware  maintenance  and 
2)  Present  the  case  for  standardizing  software  maintenance  practices  and 
those  aspects  of  software  development  methodology  that  affect  the 
maintainability  of  the  delivered  software.  Purpose  2  is  derived  from  1  on 
the  basis  that  the  kind  of  discipline  and  rigor  that  exists  in  hardware 
maintenance  should  be  an  objective  of  software  maintenance. 

Notice  that  we  do  not  contend  that  identical  methodologies  or  procedures 
should  be  used  for  software  maintenance  bec'ause  there  are  differences  in 
characteristics  and  complexities  between  the  two;  these  differences  are 
described  in  the  paper.  Rather,  we  propose  that  software  maintenance  should 
be  supported  by  a  model  of  maintenance  and  a  minimum  set  of  standardized 
practices,  which  would  be  augmented  or  tailored  according  to  the  needs  of 
individual  organizations  or  applications.  The  maintenance  model  includes 
characteristics  of  development  methodologies  because,  as  stated  previously, 
these  characteristics  affect  maintainability. 

III.  OBJECTIVES  OF  MAINTENANCE 

The  objective  of  maintenance  is  to  make  required  changes  in  software  in 
such  a  way  that  its  value  to  users  is  increased.  Required  changes  can 
result  from  either  the  need  to  correct  errors  or  to  increase  the 
functionality  of  the  software. 

A.  Maintenance  Process 

In  the  broad  view  of  maintenance,  it  is  not  limited  to  making 
post-delivery  changes  L4D.  Rather,  it  is  a  process  that  starts  with  user 
requirements  and  never  ends  E53.  Even  the  installation  of  and  changes  to  a 
replacement  system  can  be  considered  part  of  the  maintenance  process. 
Our  approach  to  identifying  the  maintenance  functions  which  should  be 
standardized  is  to:  1)  Adopt  the  view  that  maintenance  is  a  process  of 
change  management  and  2>  Identify  tasks  in  maintenance  that  are  concerned 
with  making  changes  to  software,  including  changes  to  documentation 
(e.g.,  specification,  design,  listing,  test  plan,  etc.). 
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B.  Maintenance  Tasks 


Using  the  concept  of  change  management,  the  -following  maintenance  tasks 

can  be  identified: 

o  Identify  need  for  change 

o  Determine  whether  change  should  be  made,  based  on  benefit-cost 
analysis 

o  Evaluate  the  effects  of  change,  including  possible  side  effects 

o  Determine  whether  change  can  be  made  without  creating  an 
incompatibility  with  the  rest  of  the  software 

o  Make  the  change,  if  warranted,  and  only  if  it  can  be  done  in  a 
standard  way 


C.  Differences  Between  Hardware  and  Software  Maintenance 


Whereas  failures  in  hardware  are  true  failure  events,  which  are  caused 
by  physical  phenomena  —  wearout,  burnout,  malfunction,  or  stress  — 
software  'failures*  are  error  discovery  events,  which  are  caused  by  errors 
made  by  humans.  Software  errors  are  caused  by  the  following:  inadequate  or 
misunderstood  specifications,  incorrect  program  logic,  misuse  of 
programming  language,  and  mistakes  in  clerical  operations.  These  errors 
exist  in  software  prior  to  its  execution  and  are  only  discovered  by  virtue 
of  an  input  forcing  the  software  through  an  execution  path  that  contains  an 
error . 

The  ability  to  understand  the  nature  of  errors  when  maintaining  software 
has  been  reported  to  be  related  to  the  quality  of  documentation  C63. 
Therefore  the  characteristics  of  documentation  that  affect  maintenance 
should  be  a  part  of  any  plan  to  improve  maintenance.  Documentation  for 
maintenance  is  discussed  in  the  section  'Standardization  of  Change 
Documentation  * . 

1 )  Spare  Parts 

For  software,  there  are  no  spare  parts  for  replacing  a  module  that  has 
an  error.  The  error  must  be  fixed  before  the  operation  can  continue.  This 
is  an  inherent  factor  which  makes  software  less  reliable  than  hardware. 
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Repair  times  and  down  times  can  be  very  long.  This  situation  demands  easy 
maintainability.  In  particular,  traceability  must  be  achieved:  the  ability 
to  easily  trace  through  all  relevant  documents,  organizations  and  personnel 
to r  the  purpose  of  locating  information  which  will  assist  the  maintainer  in 
correcting  the  error  in  such  a  way  that  the  change  will  not  damage  another 
part  of  the  program  that  is  working  (ripple  effect). 

2)  Prototyping 

Prototyping  of  software  is  similar  to  the  hardware  engineer's  test  bench 
and  development  systems  (e.g. ,  in  circuit  emulation  systems).  With  the 
software  prototype  we  want  to  obtain  a  quick  and  inexpensive  test  of  a 
development  idea  before  committing  a  lot  of  time,  personnel  and  money  to 
the  production  system.  Another  objective  is  to  test  design  approaches  in  a 
simplified  and  controlled  environment  without  the  confounding  interactions 
of  a  large  system  present.  If  the  ideas  won't  work  in  the  prototype,  there 
is  no  hope  of  them  working  in  the  production  system.  One  use  of  a  prototype 
seldom  mentioned  is  to  test  for  flexibility  of  making  changes  to  the 
software.  For  example,  is  the  software  constructed  so  that  the  effects  of 
making  changes  are  highly  visible? 

In  many  cases  the  prototype  is  treated  as  throwaway  code.  It  is  used  for 
the  purposes  described  and  an  improved  version,  based  on  the  lessons 
learned,  is  coded  as  the  next  prototype  or  as  the  production  system,  when 
the  design  iteration  process  ends. 

IV.  METRICS  FOR  MAINTENANCE 

In  order  to  manage  software  change  it  is  desirable  to  measure  the 
effects  of  change.  This  is  accomplished  with  quality  metrics.  A  quality 
metric  is  defined  as  follows:  a  quantitative  measure  of  the  degree  to  which 
software  possesses  a.  given  attribute  that  affects  its  quality  Cl  3.  Ideally, 
there  would  be  agreement  on  a  set  of  application-independent, 
language-independent,  software  structure-independent  metrics  (‘universal 
metrics').  Agreement  does  not  exist  in  the  software  engineering  community 
on  a  universal  set.  Lacking  this  agreement,  metrics  which  are  known  to  be 
related  to  the  effectiveness  and  efficiency  of  the  software  development 
process  are  used  during  development  to  measure  and  improve  the  development 
process;  these  are  called  process  metrics  [73.  It  is  assumed  that  their  use 
will  result  in  maintainable  software.  However,  process  metrics,  like 
traceabi 1 i ty ,  have  little  to  do  with  measuring  whether  the  system  achieves 
its  quality  requirements.  For  that  we  need  product  metrics  like 
reliability,  accuracy,  response  time,  throughput,  etc.  The  two  types  of 
metrics  are  related  in  the  sense  that  high  process  metric  values  will 
contribute  to  high  product  metric  values.  Product  metrics  are  beyond  the 
scope  of  this  paper. 
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The  role  of  metrics  in  maintenance  can  be  demonstrated  by  posing  the 
following  question! 

When  a  maintenance  action  is  taken,  how  are  the  relevant  metrics  values 
affected? 

o  What  are  the  relevant  metrics? 
o  What  were  the  original  values? 
o  What  are  the  new  values? 
o  Examine  incremental  changes 

*  Are  they  in  the  right  direction  (e.g.,  reduced  complexity)? 

*  Are  they  approximately  the  right  values  (e.g.,  within  the 
bounds  of  experience  with  respect  to  the  maintenance  action)? 


V.  MODEL  OF  MAINTENANCE 

To  explain  the  dynamic  interaction  between  development  and  maintenance 
as  exemplified  by  the  changes  in  metrics  values  as  a  result  of  development 
and  maintenance  actions,  the  model  in  Figure  1  is  provided.  A  model  of  the 
maintenance  process  is  essential  for  standardization  to  be  achieved. 
Different  organizations  may  want  to  use  different  metrics,  depending  on  the 
relevance  of  the  metrics  to  their  maintenance  environments  and  projects. 


Page  10 


Development 

Methodology 


Contributes 
to  Original 
Metrics  Values 


Affects  Ability 
to  Make  Correct 
Changes 


1 


( 


v  New  Metrics  v 

- 1  Values  ! - 

Compute  &  Recompute! - > i  Maintenance 

Common  Metrics  !< - I  Actions 


■  Changes  Metrics 
Values 


! 


v 

(Sample  List) 
Comp leteness 
Consistency 
Modularity 
Traceabi 1 ity 
Verifiability 


-I 

I 

I - >  Improved 

!  Maintainability? 


! 


v 


v 

Add 

Delete 

Modify 


1 


v 


Metrics  Data  Base 

•  _ 

1 

• 

• 

1 

1  —  —  —  —  —  —  — 

1  Maintenance  Data 

(Metrics  and 

—  > i Correl at i on 

< — !  Base  (Maintenance 

Projects  History) 

I  ? 

1 

1 

!  Action  History) 

1 

1  w 

Figure  1.  Model  of  the  Interaction  between  Development,  Maintenance 
and  Metrics. 


Page  1 1 


This  model  may  be  understood  and  applied  as  follows: 

A.  Evaluate:  Estimate  the  incremental  change  in  metric  value  of  a  proposed 
maintenance  action.  If  the  software  change  is  made,  measure  its  effect 
after  the  change  is  made.  To  the  extent  feasible,  quantify  the  effect  of 
the  change.  The  fallowing  questions  are  relevant  when  considering  a  change 
to  software: 

o  Given  the  development  methodology  and  a  maintenance  action,  how  will 
the  metrics  values  be  affected  (magnitude  and  sign)?  Will  they  change  in  a 
direction  to  indicate  the  software  will  be  (or  has  been)  improved?  Or  will 
the  change  indicate  that  the  software  will  be  (or  has  been)  degraded? 

This  model  would  assist  the  maintenance  organization  to:  11  determine 
whether  a  change  should  be  made,  2)  determine  whether  a  change  improved 
maintainabi 1 i ty ,  if  it  was  made,  and  3)  document  the  history  of  the  project 
and  the  change  so  that  this  information  can  be  used  when  making  future 
change  decisions. 

6.  Feedback:  Understand  that  taking  a  maintenance  action  changes  metrics 
values  and  that  the  new  metrics  values  will  influence  future  maintenance 
acti ons. 

C.  Data  bases:  Maintain  data  bases  of  project  characteristics,  metrics,  and 
maintenance  actions  as  an  aid  to  learning  from  the  past:  Was  a  given  metric 
a  good  predictor  of  the  effect  of  a  given  maintenance  action?  Which 
maintenance  actions  improved  and  which  degraded  the  software  for  given 
project  characteristics?  Did  the  nature  of  the  development  methodology 
influence  the  maintainability  of  the  software? 

VI.  STANDARDIZATION  OF  CHANGE  DOCUMENTATION 

Because  there  is  a  great  difference  in  applications,  programming 
environments,  etc. ,  in  various  organizations,  the  maintenance  standard 
should  accommodate  those  differences  and  specify  only  a  minimum  set  of 
requirements  and  procedures. 

Standardization  can  be  viewed  as  a  process  of  posing  questions  prior  to 
a  maintenance  action  and  having  the  maintainer  answer  them.  The  purpose  of 
this  is  to  ensure  that  the  maintainer  has  thought  about  the  consequences  of 
proposed  changes  and  is  alerted  to  potential  pitfalls.  Maintenance 
decisions  and  actions  should  be  recorded  in  a  data  base  for  use  in  making 
future  maintenance  decisions. 
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The  entities  which  are  subject  to  change  are  software  components  (an 
element  of  a  software  system  such  as  a  module  or  unit).  For  the  sake  of 
brevity,  ‘software  component'  will  hereafter  be  called  ‘component’. 

A.  Documenting  the  Effects  of  Change 

It  should  be  a  standard  procedure  of  maintenance  to  document  a  proposed 
change  in  the  following  format  (or  similar  format)  and,  if  the  change  is 
made,  to  fill  in  as  much  detail  as  possible  about  the  change.  The  items  to 
be  considered  in  deciding  on  a  change  are  more  important  than  the  specific 
format  used  to  document  the  change.  The  Xs  in  the  matrix  indicate  a 
relationship  between  an  input  item  and  an  output  item. 

Change  an  i nput 
Type 
Format 

Value  (How  are  outliers  handled?) 

Range 

Precision 

Accuracy 

Name  (Standardize  name;  should  say  what  module  does) 

Questions: 

*  What  is  the  effect  of  input  on  outputs? 

*  What  is  the  effect  of  input  on  computation  of  function? 

*  Computation  within  bounds? 
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TABLE  I 

EXAMPLE  INPUT-OUTPUT  CHANGE  RELATIONSHIP 
OUTPUT  (Name) 


Type  Format 

Value 

Range 

Precision 

Accuracy 

INPUT 

(Name) 

Type 

X 

Format 

X 

Value 

X 

X 

X 

X 

Range 

X 

X 

X 

X 

Precision 

X 

X 

X 

X 

Accuracy 


X 


X 


X 


X 


Page  14 


B.  Documentation  Requirements 

As  a  minimum  the  following  should  be  standard  documentation  for 
supporting  maintenance:  requirements  specification,  design  specification, 
program  listing,  test  plan,  and  test  results,  as  summarized  below. 

Phase  Documentation 

Requirements  Analysis  Requirements  Specif ication 

Design  Design  Specification 

Coding  Listing 

All  Test  Plan,  Test  Results 


VII.  SOFTWARE  COMMUNICATION  MECHANISMS  AND  MAINTENANCE 

Mechanisms  which  are  available  for  communicating  between  components  are 
an  important  aspect  of  maintenance  because  of  the  serious  consequences  of 
making  an  error  in  adding  or  changing  a  linkage.  As  opposed  to  other  types 
of  software  changes,  a  change  in  a  communication  mechanism  affects  more 
than  one  component.  This  is  particularly  important  for  networks  where  a 
defective  mechanism  can  adversely  affect  the  operation  of  computers  at 
remote  sites. 

A.  Kinds  of  Communication  Mechanisms 

o  Data  linkages  (for  the  transfer  of  data) 
o  Control  linkages  (for  the  transfer  of  control) 
o  Subroutine  call 
o  Procedure  call 
o  Message  passing 
o  Remote  procedure  call  (RPC) 

o  Transaction  (e.g.,  update  in  a  data  base  management  system) 

B.  Characteristics  of  Communication  Between  Software  Components 

1)  Explicit:  There  is  an  actual  transfer  or  exchange  of  data  or 

passing  of  parameters  or  an  output  from  one  component 
is  the  input  to  another  component. 

2)  Implicit:  Based  on  the  position  of  the  given  component  within  a 

sequence  of  components  (e.g.,  instructions  in  a 
program) 
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Before  components  are  added,  deleted  or  modified,  it  should  be  standard 
procedure  to  ascertain  and  document  the  effects  of  making  the  change  on 
inter  component  communication.  Furthermore,  if  the  change  is  made,  as  much 
detail  as  possible  should  be  documented  about  the  change,  as  suggested  by 
the  questions  below. 

3)  ADD  a  component 

o  What  other  components  will  the  given  component  communicate 
with  once  it  is  added? 

o  What  are  the  communication  linkages?  (parameter  passing, 
message  exchange,  RPC,  etc.?) 

o  What  existing  communication  linkages  will  be  affected  by 
the  change? 

4)  DELETE  a  component 

o  What  communication  linkage  will  be  broken  by  the  deletion? 

o  What  are  the  new  communication  linkages  that  result  from 
the  deletion? 

5)  MODIFY  a  component 

o  What  is  the  existing  communication  linkage  which  involves 
this  component? 

o  How  will  this  communication  linkage  be  modified  by  the 
change  in  the  component? 


VIII.  STANDARDIZATION  THROUGH  EXAMINATION  OF  DEVELOPMENT 
METHODOLOGIES 

There  is  evidence  that  the  characteristics  of  development  methodologies 
161  and  the  characteristics  of  programming  languages  C91  can  influence 
maintainabil ity. 
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A.  Character! sties  o-f  Development  Methodology 

When  Me  maintain  software  we  may  not  be  cognizant  of  the  development 
methodology  which  was  used  to  produce  the  software,  but  it  will  affect  our 
ability  to  maintain  the  software.  The  evaluation  hinges  on  a  single 
criterion:  does  the  methodology  support  the  creation  of  software  which  is 
easy  to  change  without  inducing  side-effects  (an  unexpected  and  undesirable 
result  of  making  a  change  ?) .  This  objective  will  be  achieved  if  the 
methodology  forces  the  designer  to  formally  consider  the  consequences  of 
making  a  change  once  the  software  has  to  be  maintained.  It  follows  that  in 
order  to  capitalize  on  a  methodology  that  supports  maintenance,  it  is 
necessary  to  use  that  methodology  to  maintain  the  software.  The  following 
is  a  standard  procedure  for  evaluating  a  methodology  with  respect  to  its 
capability  to  support  maintenance. 

Does  the  methodology  assist  to: 

1)  Prevent  side  effects  when  performing  maintenance 

2)  Provide  ability  to  make  selective  change  (i.e. ,  don't  change  or 
destroy  another  part  of  the  software  when  making  a  change) 

3)  Reduce  dependencies  between  inputs,  processes  and  outputs 
(dependices  make  it  difficult  to  change  the  software  without 

affecting  something  else  which  was  working  correctly  prior  to 
the  change) 

4)  Determine  whether  change  can  be  made  without  creating  an 
incompatibility  with  the  rest  of  the  software 

5)  Support  a  rational  change  policy: 

o  Make  a  change,  if  warranted,  and  only  if  it  can  be  done  in  a 
standard  way,  a  'standard  way'  being  defined  as  being  in 
conformance  with  the  above  procedure  for  assessing  the  impact 
of  change. 

o  Keep  changes  small 

o  Make  changes  in  small,  controlled  increments 

o  If  there  is  a  big  change  to  make,  break  the  changes  into 
manageable  pieces. 
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IX.  EXAMPLE 

A.  Characteristics  of  Development  Methodology 

The  process  of  identifying  and  evaluating  development  methodology 
principles  that  are  conducive  to  maintenance  is  illustrated  with  real 
examples  from  personal  computer  network  operating  system  software  (IBM  PC 
DOS  V3.2  C103  and  PC  LAN  Program  VI. 1  C113)  and  the  state  diagram  method  of 
specifying  software  logic  C123. 

A  batch  (command  file)  for  starting  a  user  personal  computer  on  a  local 
area  network  (LAN)  and  assigning  resources  provided  by  a  server  is  shown  in 
Figure  2  and  the  corresponding  state  diagram  is  shown  in  Figure  3.  This 
batch  file  was  modified  to  provide  some  additional  network  capabilities  as 
shown  in  Figure  2;  the  corresponding  modification  is  shown  in  Figure  3  with 
dotted  boxes.  The  boxes  represent  states  and  the  arrows  represent  state 
transitions.  The  numbers  on  the  left  side  of  the  commands  in  the  batch  file 
correspond  to  the  numbers  on  the  state  boxes  on  Figure  3.  The  convention 
for  labeling  state  transition  arrows  is:  Event /Acti on.  In  some  cases  in 
Figure  3  there  is  no  event;  in  these  cases  *NE'  is  used  to  indicate  this. 
The  DOS  and  PC  LAN  Program  handle  transfers  of  control  implicitly  (e.g.,  a 
transfer  of  control  occurs  automatically  from  PC  LAN  Program  to  DOS  under 
certain  error  conditions).  There  is  no  capability  in  the  batch  file 
language  for  describing  error  conditions  explicitly,  although  they  are 
shown  in  the  state  diagram  to  clarify  the  operation. 

Asterisks  in  the  batch  file  identify  comments.  Unfortunately,  the 
comment  concerning  accessing  the  D  drive  was  not  changed  with  the 
modification.  This  comment  is  no  longer  applicable  and  caused  confusion  in 
trying  to  understand  the  program  logic.  With  the  modification,  neither  the 
D  drive  nor  the  directory  program  1DIR  are  accessed  at  this  point  in  the 
program.  The  comment  should  have  been  changed  to  refer  to  the  E  drive  and 
the  PROFILE  program.  This  affects  the  transitions  from  states  5  to  6  and  6 
to  7.  For  the  sake  of  brevity,  the  error  events  and  actions  associated  with 
states  6'  and  7'  are  not  shown  in  Figure  3;  they  are  similar  to  those  for 
states  6  and  7. 
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Neither  a  state  diagram  nor  another  type  o-f  methodology  that  would  show 
the  consequences  o-F  making  a  change  was  used  in  creating  the  batch  program. 
The  use  of  such  a  methodology  would  have  helped  to  avoid  this  kind  of  error 
by: 


o  Preventing  side  effects  (erroneous  comment) 


o  Providing  ability  to  make  selective  change  (replace  commands  6  and  7  with 
6*  and  7'  correctly). 


o  Identifying  existing  communication  linkages  (communication  between 
commands  6  and  7  and  the  D  drive  and  its  directories)  and  by  identifying 
changed  communication  linkages  (communication  between  commands  6'  and  7' 
and  the  E  drive  and  its  directories) . 
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:  ***  Start. Bat  =  Start. TU3 

:  ***  For  Token  Ring  User.  User  3270  Emulation  on  User  Hard  Disk 
s  ***  Loads  Pro-file  Which  is  Used  for  Checking  Hardware  Compatibility 

1  ECHO  OFF 

*  *•**  Establish  Path  to  Network  and  DOS  Programs  Residing  on  User 

s  Computer 

2  PATH  C:\NETW0RK; C:\APPS\D0S 

:  #**  Establish  Access  for  1DIR  to  1D1RDATA  Sub  Directory 
APPEND  C:\1DIRDATA 
ECHO  ON 

•  ***  Load  Token-Ring  Programs 

3  TOKREUI 
NETBEUI 

:  **#  Start  the  User  Computer  on  the  Network,  Using  Name  Provided  by 
User 

4  NET  START  MSS  */.l  /SRV: 1  /ASB:  10  /PB1:16K  /USN:3  /CMDs  12  /SES:  IB 
:  ***  Request  Use  of  Server  Directories  and  Printer 

5  NET  USE  Es  WTN3NAPPS 
NET  USE  D:  \\TN3\DISKD 
NET  USE  LPT 1  \\TN3\PRINT 

:  ***  Access  D  Directory  which  Contains  1DIR  and  Program  Batch  Files 

6  D: 

***  Load  1DIR 

7  1DIR 


Modification:  Replace  commands  6  and  7  above  with  commands  6'  and  7'i 
(comment  was  not  changed) 

:  •***  Access  D  Directory  which  Contains  1DIR  and  Program  Batch  Files 

6'  E: 

:  ***  Load  Profile 
7'  PROFILE 


Figure  2.  Batch  file  for  Token-Ring  LAN  User  Computer  Start  Program 
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I  —  I  _ _ _ _ _ _ _ 

0  v  !  LOAD  START  FILE 


IDLE  ! - !  CAN'T  LOAD  START 

- !  !  FILE/ERROR  MSG. 

!  I 

!  NE/LOAD  START  FILE  FROM  DOS  ! 

1  v  v 

- j  CAN'T  LOCATE  ! - ! 

START  !  DIRECTORIES/ERROR  MSG.  i  BACK  AT  ! 

FILE  J - >!  DOS  ! 


LOADED 


:  NE/EXECUTE  PATH  &  i  ! 

!  APPEND  COMMANDS  !  ! 

2  v  !  I 

! - I  CAN'T  LOAD  TOKEN-RING  i  1 

{DIRECTOR-!  PROGRAMS/ERROR  MSG.  ! 

*  IES  i - !  i 

i  LOCATED  !  ! 

! - :  i 

{  NE/LOAD  TOKEN-RING  I 

!  PROGRAMS 

3  v  ! 

) - I  CAN'T  START  NETWORK /ERROR  MSG.  5 

i  TOKEN-  !  i 

i  ring  : - : 

!  PROGRAMS! 

!  LOADED  ! 

I - . 

i  NE/ START  NETWORK 


RESOURCES  NOT 
AVAILABLE/ERROR  MSG. 


NE/REQUEST  RESOURCES 


I 

v 


. - j 

i  : 
: RESOURCES  I 
{ASSIGNED  S 


NE/ACCESS 
DRIVE  D 


I 

! 

■>: 

j 

i 

* 

i- 


CAN'T  LOAD 
ERROR  MSG. 


1DIR/ 


AT  D 
PROMPT 


{ 

DRIVE  D  I 
ACCESSED  I 


NE/LOAD 

1DIR 


I 


{DIRECTORY! 
•>{ PROGRAM  ! 
i(lDIR)  ! 
{ LOADED  ! 


! 


■ ! 


| - 

DRIVE  NOT  DEFINED/ERROR  MSG.  !  AT  NET 
- >!  MENU 


i 


7' 


{  NE/ACCESS  .  .  NE/LOAD  .  PROFILE  . 
!  DRIVE  E  .  DRIVE  E  .  PROFILE  .  PROGRAM  . 
- >.  ACCESSED. - >.  LOADED  . 


Figure  3.  State  Diagram  o-f  a  Token-Ring  LAN  User  Computer  Start 
Program 
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It  was  mentioned  previously  that  metrics  are  part  of  the  maintenance 
model  —  they  assist  in  evaluating  the  effects  of  change.  When  used  over 
hundreds  of  components,  the  metrics  can  assume  numerical  values  (e.g. ,  for 
Completeness:  ratio  of  completed  components  to  total  number  of  components 
in  the  system).  For  a  single  component,  as  in  the  example,  a  qualitative 
interpretati on  is  appropriate.  This  is  done  below  for  the  example,  using 
typical  metrics.  Although  the  modification  has  improved  functionality,  it 
has  degraded  maintainability. 
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TABLE  2 

METRICS  APPLIED  TO  EXAMPLE  PROGRAM 

Metric  Original 

Program  Modified  Program 


Completeness: 

Are  all  required  Yes  No. The  correct  comment  is  missing. 

program  parts 

present? 


Consi stency: 

Are  the  code  and  Yes  No.  The  comment  contradicts  the 

documentation  commands  and  vice  versa, 

uniform  and  free 
of  contradiction? 


Modul ari ty: 

Is  the  structure  No 
cohesive  and  self- 
contai ned? 


No.  Quirks  of  the  DOS  language 
inhibit  modularity,  but  similar 
commands  are  grouped. 


Traceabi 1 i ty: 

Can  the  program  Yes  No.  Can't  trace  between  commands, 

parts  be  traced  drives  and  directories, 

from  one  to 

another? 


Veri f iabi 1 i ty: 

Can  the  correct  Yes  No.  The  erroneous  comment  confuses 

operation  and  the  veri f i cation. 

performance  of 

the  program  be 

verified? 
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B.  Character! sties  of  Programming  Language 

Characteri sti cs  o-f  the  programming  language  can  also  significantly 
influence  the  ability  to  maintain  £93.  Two  brief  examples  from  the  DOS 
language  £103  will  be  given: 

o  PATH  command:  If  this  command  appears  once  and  is  repeated,  the  most 
recent  occurrence  of  the  command  is  the  only  one  in  effect.  This  means  that 
any  paths  used  to  establish  directories  in  a  previous  occurrence  are  lost 
unless  they  are  repeated  in  the  new  PATH  command.  In  effect,  this  means 
that  a  new  path  must  be  a  superset  of  the  previous  path,  if  all  original 
directory  information  is  to  be  retained.  However,  this  could  result  in  long 
path  commands  and,  without  writing  complicated  logic,  commands  are  limited 
to  a  single  line!  Thus  the  maintenance  principle  of  being  able  to  make  a 
selective  change  <i.e. ,  one  wants  to  just  add  or  delete  parts  of  the  PATH 
command,  not  write  a  new  one)  cannot  be  achieved  with  this  command. 

o  IF  command:  The  IF  command  has  the  format:  IF  string l==stri ng2  command. 
The  requirement  for  the  second  is  unexpected.  This  nuance  of  the 
language  has  caused  several  errors  in  implementing  network  batch  files. 
This  seemingly  minor  item  can  cause  havoc  in  maintenance  because  a  frequent 
change  to  batch  files  occurs  as  the  result  of  adding  capabilities  to  the 
network  that  are  conditioned  on  the  availability  of  certain  resources.  The 
IF  command  is  key  to  specifying  these  conditions. 

X.  FURTHER  RESEARCH 

Further  research  is  necessary  to  examine  development  methodologies  in 
more  detail  with  respect  to  their  influence  on  maintainability,  for  example 
the  object  oriented  approach  £93.  The  objectives  of  this  paper  have  been  to 
make  a  start  towards  the  goal  of  standardizing  maintenance  bv  proposing 
that  a  change  management  methodology  is  the  key  to  standardization,  and  to 
begin  a  dialogue  with  the  software  engineering  community  concerning 
approaches  for  standardizing  maintenance.  The  objective  has  not  been  to 
solve  the  whole  problem,  which  is  complex. 
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X I .  SUMMARY 

We  have  contrasted  software  maintenance  with  hardware  maintenance. 
Although  there  are  similarities,  the  major  difference  —  the  ease  of 
changing  software  —  causes  unique  software  maintenance  problems.  We  have 
proposed  that  maintenance  can  be  improved  through  standardization.  The 
elements  of  the  proposed  standardi zati on  process  are  the  following: 

o  Metrics 

o  Model  of  maintenance 
o  Change  documentation 
o  Software  communication  mechanisms 

o  Development  methodology  supportive  of  maintenance 

An  example  was  presented  of  the  application  of  one  development 
methodology  —  state  diagrams  —  to  illustrate  how  proposed  and 
accomplished  changes  can  be  illuminated  so  that  errors  can  be  avoided  and 
maintainability  improved. 

Finally,  we  stated  that  because  the  maintenance  problem  is  so  complex, 
more  research  must  be  done  —  particularly  on  the  relationship  between 
development  methodologies  and  maintainability  —  before  maintenance  can  be 
standardized.  However,  we  feel  that  the  first  four  elements  —  metrics, 
model  of  maintenance,  change  documentation,  and  software  communication 
mechanisms  —  have  merit  and  that  NAVMASSO  should  evaluate  them  for 
possible  adoption. 
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